[PAR-778] Bump integration-core to ^5.1.3 and register AdvancedSettings entity#17
Merged
mescalantea merged 5 commits intoMay 22, 2026
Merged
Conversation
Register the new AdvancedSettings DataAccess entity in BootstrapComponent::initRepositories so the lazy resolution of AdvancedSettingsRepositoryInterface succeeds under v5.1. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ed-account impersonation integration-core v5.1.2 sends ConnectionData::merchantId only via the Sequra-Merchant-Id HTTP header (AuthorizedProxy). Simba's StoreIntegrationsController reads params[:merchant_id] from the request body / query string, not from headers, and the shared-account impersonation path (authorize_merchant_access) returns 403 when the param is missing. Without this fix, every POST / DELETE from a service-type api_account fails authorization. The new MerchantIdAwareStoreIntegrationProxy: - POST: appends merchant_id to the JSON body root (same level as store_integration). - DELETE: appends merchant_id as a URL query parameter on the resource path /store_integrations/<encoded_webhook_url>. - No-op when merchantId is null/empty, so non-shared-account callers see no behavior change. Registered in BootstrapComponent after parent::initServices() so the override wins over core's default StoreIntegrationProxy. No core changes; the body/query placement is a deployment-topology concern of the shared-account model that every middleware consumer shares. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Simba PR 19469 reads merchant_id from the Sequra-Merchant-Id header that integration-core's AuthorizedProxy already sends; the body/query injection is no longer needed. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… fix branch Temporary dev-branch reference until sequra/integration-core#60 is merged and tagged. The "as 5.1.999" alias keeps the dev branch satisfying the previous "^5.1" semantic so downstream consumers don't need their own composer.json change to pick this up — only a composer update. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is the goal?
Bump
sequra/integration-coreto the released^5.1.3and apply the minimum middleware-side changes needed for v4 → v5.1 compatibility. This unblocks the downstream SeQura Marketing App PAR-778 work, which depends on the v5.1AuthorizedProxythat forwards merchant id via theSequra-Merchant-Idheader.References
How is it being implemented?
Net changes against master:
composer.json— bumpsequra/integration-corefrom^4.0to^5.1.3.composer.lock— regenerated.src/BootstrapComponent.php— register the newAdvancedSettingsDataAccess entity ininitRepositories()so the lazy resolution ofAdvancedSettingsRepositoryInterfacesucceeds under v5.1.No middleware-side merchant-id forwarding code is needed: v5.1.3's
AuthorizedProxysendsSequra-Merchant-Idas an HTTP header, and the downstream Simba PR reads it from there. A transitionalMerchantIdAwareStoreIntegrationProxywas added and then removed earlier on this branch once the upstream header contract landed — net diff is zero for that file.Caveats
integration-core4 → 5.1). Downstream integrators will be forced onto core v5.1 and should cut a corresponding major release of their own.Does it affect (changes or update) any sensitive data?
No.
How is it tested?
How is it going to be deployed?
composer.jsonpinned to^5.1.3🤖 Generated with Claude Code